In a proposed multicast implementation, multiple forwarding tag (“FTAG”) multicast trees are constructed from the dense bipartite graph of fabric nodes/edges and each such multicast tree (henceforth called “FTAG” tree) is used to forward a multicast packet for distribution to various fabric edge switches (“ToRs”). Multiple trees are created for load balancing purposes. An external controller decides a suitable root node for each FTAG instance and distributes this information to all the member switches of a fabric. The FTAG trees are created in a distributed manner where each node independently decides which local links should be included in a given instance of an FTAG tree.
During construction of an FTAG tree using the distributed methodology that each node uses, there exists the possibility that a loop will be created if the network view of the various nodes has not converged. i.e. if one node's view of the network topology differs from another's node's view of the same network topology. This occurs because there is a non-significant delay for infra-network routing protocol updates such as intermediate system-to-intermediate system (“IS-IS”) or other intra-domain link state routing protocol updates such as Open Shortest Path First (“OSPF”) updates to converge when there is simultaneous network link transition. Loops are problematic from multicast tree point-of-view because there can be duplicate packets delivered to end nodes if loops are created in the tree. Thus, care must be taken to ensure that during any instance of FTAG creation there is no intermediate loop in the FTAG tree, and no delay in tree creation, such as when tree construction happens in a serial or lock-step manner.